Adaptive resolution of domain name requests in virtual private cloud network environments

ABSTRACT

Systems and methods are described to enable adaptive handling of domain resolution requests originating from a virtual private cloud (VPC) networking environment. An administrator of the VPC can provide a set of rules specific to the VPC that designates how requests for a domain name should be handled. The rules may specify, for example, that a request for a given domain name should be routed to a particular domain name server, which may include a private domain name server, should be dropped, or should be routed according to a default behavior (e.g., a public domain name system). Resolution requests originating in the VPC can be associated with a VPC identifier. When an adaptive resolution system receives the request, it can retrieve rules associated with the VPC identifier, and apply the rules to determine further routing for the request.

BACKGROUND

Generally described, computing devices utilize a communication network,or a series of communication networks, to exchange data. Companies andorganizations operate computer networks that interconnect a number ofcomputing devices to support operations or provide services to thirdparties. The computing systems can be located in a single geographiclocation or located in multiple, distinct geographic locations (e.g.,interconnected via private or public communication networks).Specifically, data centers or data processing centers, herein generallyreferred to as “data centers,” may include a number of interconnectedcomputing systems to provide computing resources to users of the datacenter. The data centers may be private data centers operated on behalfof an organization or public data centers operated on behalf, or for thebenefit of, the general public.

To facilitate increased utilization of data center resources,virtualization technologies may allow a single physical computing deviceto host one or more instances of virtual machines that appear andoperate as independent computing devices to users of a data center. Withvirtualization, the single physical computing device can create,maintain, delete or otherwise manage virtual machines in a dynamicmatter. In turn, users can request computer resources from a datacenter, including single computing devices or a configuration ofnetworked computing devices, and be provided with varying numbers ofvirtual machine resources.

Generally, physical networks include a number of hardware devices thatreceive packets from a source network component and forward the packetsto designated recipient network components. In physical networks, packetrouting hardware devices are typically referred to as routers, which areimplemented on stand-alone computing devices connected to a physicalnetwork. With the advent of virtualization technologies, networks androuting for those networks can now be simulated using commoditycomputing devices rather than actual routers.

Virtualized networks provide advantages over traditional networks, inthat the can be rapidly created, configured, or destroyed withoutreconfiguring underlying physical hardware devices. However, they canalso add a layer of complexity over traditional systems. For example,virtualized systems may not have direct physical addresses, astraditional systems would, making transmission of communications betweenvirtualized systems more difficult. Moreover, at least some virtualizedsystems may be configured to be private, such that public networkaddressing schemes, which otherwise serve to enable communicationsbetween virtualized systems, are not directly usable to communicatebetween virtualized systems. Thus, existing functionalities andpractices may not be directly usable on virtualized systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an embodiment of a substratenetwork having computing nodes associated with a virtual computernetwork;

FIG. 2 is a block diagram of the substrate network of FIG. 1illustrating logical networking functionality;

FIG. 3 is a block diagram of logical view of the substrate network ofFIG. 1 illustrating hosted virtual private cloud (VPC) networks, as wellas an adaptive domain name system (DNS) resolver to configured toresolve DNS requests from device of a VPC based on rules associated withthe VPC;

FIG. 4 is a block diagram depicting an illustrative configuration of oneembodiment of a server than may implement an adaptive DNS resolver;

FIGS. 5A and 5B are block diagrams depicting illustrative interactionsof a VPC with an adaptive DNS resolver to resolve a DNS requestaccording to rules of the VPC; and

FIG. 6 is a flow chart depicting an illustrative routine for providingadaptive DNS based on rules associated with a VPC.

DETAILED DESCRIPTION

Generally described, the present disclosure relates to managing domainname system (DNS) requests in a virtual private cloud networkenvironment, and specifically, to enabling administrators or users of avirtual private cloud network environment to control how DNS requestsfrom the virtual private cloud network environment are handled based onone or more specified rules that can be configured by administrators orusers of the virtual private cloud network environment. As used herein,the term “virtual private cloud network environment” (sometimesshortened to “virtual private cloud” or simply “VPC”) refers to avirtualized network environment, in which a collection of computingdevices are enabled by a substrate network to communicate as if thecollection of computing devices existed within a local area network(LAN) environment. Accordingly, the devices within a VPC may often sharea common subnet, and (from the perspective of the devices) directlycommunicate with one another without the use of complex routingprotocols. However, unlike traditional LANs, the devices within a VPCneed not share a direct physical interconnection. Instead, the devicesmay be located in geographically diverse regions, and in some instancesmay themselves be virtual devices (e.g., virtual machines). A substrate(e.g., physical) network, as will be described below, may encapsulate orotherwise alter communications from devices associated with the VPC tocreate the illusion, from the point of view of devices within the VPC,that a LAN environment exists.

VPCs provide many advantages over traditional LANs, in that theconfiguration of computing devices can be changed dynamically, viasoftware, without changing a physical configuration of devices.Moreover, VPCs maintain many benefits of traditional LANs, in thatcommunications between the computing devices are relatively simple andsecure. However, the managed nature of VPCs can present configurationchallenges to users of the VPCs. For example, while a VPC may provideservices to devices of the VPC, such as DNS resolution, those servicesmay not be configurable by the end user. While the user might be able toestablish a private DNS resolution server, this would result inincreased usage of computing resources and inefficiency compared tousing the provided services of the VPC, particularly if such a privateDNS resolution server is configured to handle all traffic stemming froma VPC. Moreover, it is relatively common for users of a VPC to maintaina distinct network in addition to that of the VPC (e.g., a “on-premises”network within a distinct data center). However, routing requestsbetween a VPC and a distinct network may be difficult.

Embodiments of the present disclosure address these and other issues byproviding an adaptive DNS resolution system, whereby DNS requestsstemming from a VPC can be processed or forwarded to different DNSservers based on rules established by an administrator or user of a VPC.Accordingly, an administrator of a VPC may specify that requests for afirst domain name should be routed to a private DNS server within theVPC, that requests for a second domain name should be routed to aprivate DNS server in a distinct data center, and that requests for athird domain name should be handled via a public DNS system (e.g., viathe normal functionality provided to the VPC by a hosting system). Insome instances, an administrator of a VPC may further specify resolutionrules for a domain name directly (e.g., a domain should be resolved to aspecific internet protocol [IP] address, or may specify that a domainname should be “blackholed” (e.g., resolution requests for that domainshould not be processed, which may at least partially prevent users fromaccessing the domain name)). Thus, by use of an adaptive DNS resolutionsystem, DNS requests of a VPC may be handled by a number of differentDNS servers or systems, as appropriate for the request. By distributingDNS requests between appropriate DNS servers or systems, the overallefficiency of the system is increased. Moreover, the adaptive DNSresolution system described herein can be configured to provide the sameor similar functionality to multiple VPCs, where each VPC may beassociated with rules specific to that VPC. Thus, by providing acentralized adaptive DNS resolution system, embodiments described hereinoperate more efficiently than would separate DNS systems operatingindependently for each VPC.

As will be appreciated by one of skill in the art in light of thepresent disclosure, the embodiments disclosed herein improve the abilityof computing systems, such as those implementing virtual private cloudnetwork environments, to communicate over a variety of networks, suchpublic networks, networks internal to a VPC, or networks internal to adistinct data center. Specifically, aspects of the present disclosureenable adaptive resolution of DNS requests based on VPCs from which therequests are received as well as rules provided by administrators of theVPCs. Moreover, the presently disclosed embodiments address technicalproblems inherent within computing systems; specifically, thedifficulties and complexities created by routing DNS requests withinhosted virtual networks. These technical problems are addressed by thevarious technical solutions described herein, including the creation ofan adaptive DNS resolver to take actions on DNS requests based on asource VPC of the request and rules specified by an administrator of theVPC. Thus, the present disclosure represents an improvement on existingvirtual network systems and computing systems in general.

The following section discusses various embodiments of managed networksfor network data transmission analysis. Following that is furtherdiscussion of systems and methods enabling source-dependent addressresolution.

Managed Computer Networks for Network Data Transmission Analysis

With the advent of virtualization technologies, networks and routing forthose networks can now be simulated using commodity hardware components.For example, virtualization technologies can be adapted to allow asingle physical computing machine to be shared among multiple virtualnetworks by hosting one or more virtual machines on the single physicalcomputing machine. Each such virtual machine can be a softwaresimulation acting as a distinct logical computing system that providesusers with the illusion that they are the sole operators andadministrators of a given hardware computing resource. In addition, asrouting can be accomplished through software, additional routingflexibility can be provided to the virtual network in comparison withtraditional routing. As a result, in some implementations, supplementalinformation other than packet information can be used to determinenetwork routing.

Aspects of the present disclosure will be described with regard toillustrative logical networking functionality for managed computernetworks, such as for virtual computer networks that are provided onbehalf of users or other entities. In at least some embodiments, thetechniques enable a user to configure or specify a network topology,routing costs, routing paths and/or other information for a virtual oroverlay computer network including logical networking devices that areeach associated with a specified group of multiple physical computingnodes. For example, a user (e.g., a network administrator for anorganization) or service provider may configure a virtual or overlaynetwork based on detected events, processing criteria, or upon request.With the network configuration specified for a virtual computer network,the functionally and operation of the virtual network can be simulatedon physical computing nodes operating virtualization technologies. Insome embodiments, multiple users or entities (e.g. businesses or otherorganizations) can access the system as tenants of the system, eachhaving their own virtual network in the system. In one embodiment, auser's access and/or network traffic is transparent to other users. Forexample, even though physical components of a network may be shared, auser of a virtual network may not see another user's network traffic onanother virtual network if monitoring traffic on the virtual network.

By way of overview, FIGS. 1 and 2 discuss embodiments wherecommunications between multiple computing nodes of the virtual computernetwork emulate functionality that would be provided by logicalnetworking devices if they were physically present. In some embodiments,some or all of the emulation are performed by an overlay network managersystem. One skilled in the relevant art will appreciate, however, thatthe disclosed virtual computer network is illustrative in nature andshould not be construed as limiting.

Overlay Network Manager

FIG. 1 is a network diagram illustrating an embodiment of an overlaynetwork manager system (ONM) for managing computing nodes associatedwith a virtual computer network. Virtual network communications can beoverlaid on one or more intermediate physical networks in a mannertransparent to the computing nodes. In this example, the ONM systemincludes a system manager module 110 and multiple communication managermodules 109 a, 109 b, 109 c, 109 d, 150 to facilitate the configuringand managing communications on the virtual computer network.

The illustrated example includes an example data center 100 withmultiple physical computing systems operated on behalf of the ONMsystem. The example data center 100 is connected to a global internet135 external to the data center 100. The global internet can provideaccess to one or more computing systems 145 a via private network 140,to one or more other globally accessible data centers 160 that each havemultiple computing systems, and to one or more other computing systems145 b. The global internet 135 can be a publicly accessible network ofnetworks, such as the Internet, and the private network 140 can be anorganization's network that is wholly or partially inaccessible fromcomputing systems external to the private network 140. Computing systems145 b can be home computing systems or mobile computing devices thateach connects directly to the global internet 135 (e.g., via a telephoneline, cable modem, a Digital Subscriber Line (“DSL”), cellular networkor other wireless connection, etc.).

The example data center 100 includes a number of physical computingsystems 105 a-105 d and a Communication Manager module 150 that executeson one or more other computing systems. The example data center furtherincludes a System Manager module 110 that executes on one or morecomputing systems. In this example, each physical computing system 105a-105 d hosts multiple virtual machine computing nodes and includes anassociated virtual machine (“VM”) communication manager module (e.g., aspart of a virtual machine hypervisor monitor for the physical computingsystem). Such VM communications manager modules and VM computing nodesinclude VM Communication Manager module 109 a and virtual machines 107 aon host computing system 105 a, and VM Communication Manager module 109d and virtual machines 107 d on host computing system 105 d.

This illustrative data center 100 further includes multiple physicalnetworking devices, such as switches 115 a-115 b, edge router devices125 a-125 c, and core router devices 130 a-130 c. Switch 115 a is partof a physical sub-network that includes physical computing systems 105a-105 c, and is connected to edge router 125 a. Switch 115 b is part ofa distinct physical sub-network that includes the System Manager module110, and is connected to edge router 125 b. The physical sub-networksestablished by switches 115 a-115 b, in turn, are connected to eachother and other networks (e.g., the global internet 135) via anintermediate communication network 120, which includes the edge routers125 a-125 c and the core routers 130 a-130 c. The edge routers 125 a-125c provide gateways between two or more sub-networks or networks. Forexample, edge router 125 a provides a gateway between the physicalsub-network established by switch 115 a and the interconnection network120, while edge router 125 c provides a gateway between theinterconnection network 120 and global internet 135. The core routers130 a-130 c manage communications within the interconnection network120, such as by routing or otherwise forwarding packets or other datatransmissions as appropriate based on characteristics of such datatransmissions (e.g., header information including source and/ordestination addresses, protocol identifiers, etc.) and/or thecharacteristics of the interconnection network 120 itself (e.g., routesbased on the physical network topology, etc.).

The System Manager module 110 and Communication Manager module 109 canconfigure, authorize, and otherwise manage communications betweenassociated computing nodes, including providing logical networkingfunctionality for one or more virtual computer networks that areprovided using the computing nodes. For example, Communication Managermodule 109 a and 109 c manages associated virtual machine computingnodes 107 a and 107 c and each of the other Communication Managermodules can similarly manage communications for a group of one or moreother associated computing nodes. The Communication Manager modules canconfigure communications between computing nodes so as to overlay avirtual network over one or more intermediate physical networks that areused as a substrate network, such as over the interconnection network120.

Furthermore, a particular virtual network can optionally be extendedbeyond the data center 100, such as to one or more other data centers160 which can be at geographical locations distinct from the first datacenter 100. Such data centers or other geographical locations ofcomputing nodes can be inter-connected in various manners, including viaone or more public networks, via a private connection such as a director VPN connection, or the like. In addition, such data centers can eachinclude one or more other Communication Manager modules that managecommunications for computing systems at that data. In some embodiments,a central Communication Manager module can coordinate and managecommunications among multiple data centers.

Thus, as one illustrative example, one of the virtual machine computingnodes 107 a 1 on computing system 105 a can be part of the same virtuallocal computer network as one of the virtual machine computing nodes 107d 1 on computing system 105 d. The virtual machine 107 a 1 can thendirect an outgoing communication to the destination virtual machinecomputing node 107 d 1, such as by specifying a virtual network addressfor that destination virtual machine computing node. The CommunicationManager module 109 a receives the outgoing communication, and in atleast some embodiments determines whether to authorize the sending ofthe outgoing communication. By filtering unauthorized communications tocomputing nodes, network isolation and security of entities' virtualcomputer networks can be enhanced.

The Communication Manager module 109 a can determine the actual physicalnetwork location corresponding to the destination virtual networkaddress for the communication. For example, the Communication Managermodule 109 a can determine the actual destination network address bydynamically interacting with the System Manager module 110, or can havepreviously determined and stored that information. The CommunicationManager module 109 a then re-headers or otherwise modifies the outgoingcommunication so that it is directed to Communication Manager module 109d using an actual substrate network address.

When Communication Manager module 109 d receives the communication viathe interconnection network 120, it obtains the virtual destinationnetwork address for the communication (e.g., by extracting the virtualdestination network address from the communication), and determines towhich virtual machine computing nodes 107 d the communication isdirected. The Communication Manager module 109 d then re-headers orotherwise modifies the incoming communication so that it is directed tothe destination virtual machine computing node 107 d 1 using anappropriate virtual network address for the virtual computer network,such as by using the sending virtual machine computing node 107 a 1'svirtual network address as the source network address and by using thedestination virtual machine computing node 107 d 1's virtual networkaddress as the destination network address. The Communication Managermodule 109 d then forwards the modified communication to the destinationvirtual machine computing node 107 d 1. In at least some embodiments,before forwarding the incoming communication to the destination virtualmachine, the Communication Manager module 109 d can also performadditional steps related to security.

Further, the Communication Manager modules 109 a and/or 109 c on thehost computing systems 105 a and 105 c can perform additional actionsthat correspond to one or more logical specified router devices lyingbetween computing nodes 107 a 1 and 107 c 1 in the virtual networktopology. For example, the source computing node 107 a 1 can direct apacket to a logical router local to computing node 107 a 1 (e.g., byincluding a virtual hardware address for the logical router in thepacket header), with that first logical router being expected to forwardthe packet to the destination node 107 c 1 via the specified logicalnetwork topology. The source Communication Manager module 109 a receivesor intercepts the packet for the logical first router device and canemulate functionality of some or all of the logical router devices inthe network topology, such as by modifying a TTL (“time to live”) hopvalue for the communication, modifying a virtual destination hardwareaddress, and/or otherwise modify the communication header.Alternatively, some or all the emulation functionality can be performedby the destination Communication Manager module 109 c after it receivesthe packet.

By providing logical networking functionality, the ONM system providesvarious benefits. For example, because the various Communication Managermodules manage the overlay virtual network and can emulate thefunctionality of logical networking devices, in certain embodimentsspecified networking devices do not need to be physically implemented toprovide virtual computer networks, allowing greater flexibility in thedesign of virtual user networks. Additionally, correspondingmodifications to the interconnection network 120 or switches 115 a-115 bare generally not needed to support particular configured networktopologies. Nonetheless, a particular network topology for the virtualcomputer network can be transparently provided to the computing nodesand software programs of a virtual computer network.

Logical/Virtual Networking

FIG. 2 illustrates a more detailed implementation of the ONM system ofFIG. 1 supporting logical networking functionality. The ONM systemincludes more detailed embodiments of the ONM System Manager and ONMCommunication Manager of FIG. 1. In FIG. 2, computing node A is sendinga communication to computing node H, and the actions of the physicallyimplemented modules 210 and 260 and devices of network 250 in actuallysending the communication are shown, as well as emulated actions of thelogical router devices 270 a and 270 b in logically sending thecommunication.

In this example, computing nodes A 205 a and H 255 b are part of asingle virtual computer network for entity Z. However, computing nodescan be configured to be part of two distinct sub-networks of the virtualcomputer network and the logical router devices 270 a and 270 b separatethe computing nodes A and H in the virtual network topology. Forexample, logical router device J 270 a can be a local router device tocomputing node A and logical router device L 270 b can be a local routerdevice to computing node H.

In FIG. 2, computing nodes A 205 a and H 255 b includes hardwareaddresses associated with those computing nodes for the virtual computernetwork, such as virtual hardware addresses that are assigned to thecomputing nodes by the System Manager module 290 and/or theCommunication Manager modules R 210 and S 260. In this example,computing node A has been assigned hardware address “00-05-02-0B-27-44,”and computing node H has been assigned hardware address“00-00-7D-A2-34-11.” In addition, the logical router devices J and Lhave also each been assigned hardware addresses, which in this exampleare “00-01-42-09-88-73” and “00-01-42-CD-11-01,” respectively, as wellas virtual network addresses, which in this example are “10.0.0.1” and“10.1.5.1,” respectively. The System Manager module 290 maintainsprovisioning information 292 that identifies where each computing nodeis actually located and to which entity and/or virtual computer networkthe computing node belongs.

This example, computing node A 205 a first sends an address resolutionprotocol (ARP) message request 222-a for virtual hardware addressinformation, where the message is expected to first pass through alogical device J before being forwarded to computing node H.Accordingly, the ARP message request 222-a includes the virtual networkaddress for logical router J (e.g., “10.0.0.1”) and requests thecorresponding hardware address for logical router J.

Communication Manager module R intercepts the ARP request 222-a, andobtains a hardware address to provide to computing node A as part ofspoofed ARP response message 222-b. The Communication Manager module Rcan determine the hardware address by, for example, looking up varioushardware address information in stored mapping information 212, whichcan cache information about previously received communications.Communication Manager module R can communicate 227 with the SystemManager module 290 to translate the virtual network address for logicalrouter J.

The System Manager module 290 can maintain information 294 related tothe topology and/or components of virtual computer networks and providethat information to Communication Manager modules. The CommunicationManager module R can then store the received information as part ofmapping information 212 for future use. Communication Manager module Rthen provides computing node A with the hardware address correspondingto logical router J as part of response message 222-b. While request222-a and response message 222-b actually physically pass betweencomputing node A and Communication Manager module R, from the standpointof computing node A, its interactions occur with local router device J.

After receiving the response message 222-b, computing node A 205 acreates and initiates the sending of a communication 222-c to computingnode H 255 b. From the standpoint of computing node A, the sentcommunication will be handled as if logical router J 270 a werephysically implemented. For example, logical router J could modify theheader of the communication 265 a and forward the modified communication265 b to logical router L 270 a, which would similarly modify the headerof the communication 265 b and forward the modified communication 265 cto computing node H. However, communication 222-c is actuallyintercepted and handled by Communication Manager module R, whichmodifies the communication as appropriate, and forwards the modifiedcommunication over the interconnection network 250 to computing node Hby communication 232-3. Communication Manager module R and/orCommunication Manager module S may take further actions in this exampleto modify the communication from computing node A to computing node H orvice versa to provide logical networking functionality. For example,Communication Manager module S can provides computing node H with thehardware address corresponding to logical router L as part of responsemessage 247-e by looking up the hardware address in stored mappinginformation 262. In one embodiment, a communication manager or computingnode encapsulates a packet with another header or label where theadditional header specifies the route of the packet. Recipients of thepacket can then read the additional header and direct the packetaccordingly. A communication manager at the end of the route can removethe additional header.

A user or operator can specify various configuration information for avirtual computer network, such as various network topology informationand routing costs associated with the virtual 270 a, 270 b and/orsubstrate network 250. In turn, the ONM System Manager 290 can selectvarious computing nodes for the virtual computer network. In someembodiments, the selection of a computing node can be based at least inpart on a geographical and/or network location of the computing node,such as an absolute location or a relative location to a resource (e.g.,other computing nodes of the same virtual network, storage resources tobe used by the computing node, etc.). In addition, factors used whenselecting a computing node can include: constraints related tocapabilities of a computing node, such as resource-related criteria(e.g., an amount of memory, an amount of processor usage, an amount ofnetwork bandwidth, and/or an amount of disk space), and/or specializedcapabilities available only on a subset of available computing nodes;constraints related to costs, such as based on fees or operating costsassociated with use of particular computing nodes; or the like.

Further details regarding operation of a substrate network, such as theimplementation of route selection on a substrate networks andvirtualized networks are discussed in more detail in U.S. Pat. No.9,183,028, issued Nov. 10, 2015, entitled “MANAGING VIRTUAL COMPUTINGNODES,” (the “'028 patent”), the entirety of which is incorporated byreference herein.

Adaptive Resolution of DNS Requests of VPCs

With reference to FIGS. 3-6 aspects of the present disclosure will bedescribed that enable adaptive resolution of DNS requests obtain fromcomputing devices sharing a virtual private cloud networking environment(e.g., a LAN virtualized within the substrate network described above).Specifically, as will be described below, DNS requests of computingdevices within a VPC may be processed by an adaptive DNS resolver, anddifferent actions may be taken by the adaptive DNS resolver based on asource VPC of the request as well as rules associated with the sourceVPC by, e.g., an administrator of the VPC. Thus, as described below,processing of DNS requests within a VPC may distributed between a numberof different private or public DNS servers, or may be otherwise handled,according to the specifications of a VPC administrator.

Specifically, with reference to FIG. 3, a block diagram showing asimplified logical environment 800 created at least partially by thesubstrate network 100 of FIG. 1 will be described. As shown in FIG. 3,the logical environment 800 includes one or more public DNS servers 860,one or more data centers 850, and a hosting system 802. Theconfiguration and operation of public DNS servers 860 is known withinthe art, and will not be described in detail herein. However, in brief,public DNS servers 860 can operate to receive and process requests toresolve domain names into corresponding network (e.g., IP) addresses. Insome instances, a public DNS server 860 may have first-hand knowledge ofthe network address associated with a domain name, and return thatnetwork address directly. In other instances, a public DNS server 860may interact with other public DNS servers 860 (e.g., via recursivelookup) to obtain a network address before returning that address to arequesting device. In the illustrative example of FIG. 3, the public DNSservers 860 operate according to protocols and procedures established bythe Internet Corporation for Assigned Names and Numbers (ICANN).

The operation of data centers 850 is also generally known within theart. In brief, data centers can include an interconnected set ofcomputing devices or other computing resources configured to implementfunctionality on behalf of an administrator, operator or owner of thedata center 850. For example, a data center 850 may be owned andoperated by a corporation and implement functionality on behalf of thatcorporation. As an additional example, a data center 850 may be ownedand operated by a service provider and implement functionality for avariety of different corporations. As shown in FIG. 3, each data center850 can include one or more servers 854. Further, each data center 850may include a customer DNS server 852 configured to obtain and respondto DNS requests associated with the data center 850. Illustratively, acustomer DNS server 852 may be configured to service requests only fromapproved sources, such as network addresses within the data center 850or other approved networks. In this manner, the customer DNS server 852can operate to resolve “private” domains, such as domains intended tofunction only for the servers 854 or other trusted devices.

The public DNS servers 860 and data centers 850 may communicate over apublic network 870, which can include any wired network, wirelessnetwork or combination thereof. In addition, the public network 870 maybe a personal area network, local area network, wide area network, cablenetwork, satellite network, cellular telephone network, or combinationthereof. In the illustrated embodiment, the public network 870 is theInternet. Protocols and components for communicating via the Internet orany of the other aforementioned types of communication networks are wellknown to those skilled in the art of computer communications and thus,need not be described in more detail herein.

FIG. 3 further includes a hosting system 802 in communication with thepublic DNS servers 860 and the data centers 850 via the public network870. As shown in FIG. 3, the hosting system 802 includes one or morevirtual private clouds 800 (VPCs), which represent private virtualizednetworks implemented by a substrate network, such as the substratenetwork described with respect to FIGS. 1 and 2. Each VPC includes, forexample, one or more servers 814, a private domain name system (DNS)resolver 812, and a health check endpoint 816. The servers 814 maygenerally provide any network-accessible functionality, such as web pagehosting or database hosting, among many others known in the art. Theprivate DNS resolver 812 may provide DNS functionality to the servers814 within a VPC 810. Systems and methods for implementing private DNSservers 812 associated with VPCs are described in more detail in in U.S.patent application Ser. No. 14/750,698, entitled “SELECTIVE ROUTING OFDOMAIN NAME SYSTEM (DNS) REQUESTS” and filed Jun. 25, 2016 (hereinafter,the “'698 application”), which is hereby incorporated by reference. Theprivate DNS resolver 812 and the servers 814 may be implemented, forexample, as virtual machines hosted by physical computing devices of asubstrate network. In some instances, VPCs 810 may include additional oralternative components than those shown in FIG. 3, or may exclude acomponent shown in FIG. 3. For example, embodiments of the presentdisclosure may function regardless of whether a VPC includes a privateDNS resolver 812. While shown as included within a VPC 810, private DNSresolver 812 may in some instances be logically separate from a VPC 810to which they provide DNS functionality. For example, one or moredistinct VPCs 810 may be created to contain a set of private DNSresolvers 812, each of which is associated with and provides DNSservices to one or more customer VPCs 810. Separation of private DNSresolvers 812 from a serviced VPC 810 may, for example, enablepermissions or communications channels of the private DNS resolver 812to be modified without altering or compromising security of a customer'sVPC 810. Thus, the arrangement of elements within the VPCs 810 isintended to be illustrative.

The hosting system 802 further includes a communication manager 820enabling communication with and between the VPCs 810. Specifically, thecommunication manager 816 can be configured to route the network data onan internal network 830 based on identifiers associated with the VPCs810. Like the public network 870, the internal network 830 can includeany wired network, wireless network or combination thereof. In addition,the internal network 830 may be a personal area network, local areanetwork, wide area network, cable network, satellite network, cellulartelephone network, or combination thereof.

In operation, the communication manager 816 may be configured tomaintain a mapping of VPC identifiers (which may include any datauniquely identifying VPCs 810) to network addresses on the substratenetwork that are associated with those VPCs 810. Thereafter, when thecommunication manager 816 receives a request to communicate with a VPC810, the communication manager 816 can determine an appropriate networkaddress to which to route the communication, and can either return thatnetwork address to a requesting device or act as a proxy forcommunications between the requesting device and the destination VPC810. In one embodiment, communications between a requested device (whichitself may be included in a VPC 810) and a target VPC 810 may utilizeencapsulation, such that data packets created by an originating deviceare encapsulated by a device of the substrate network (e.g., a devicehosting a virtual machine of a VPC 810, a peering gateway of the VPC810, or the like), with an identifier of the destination VPC included asmetadata or flags within the encapsulated packet. Thereafter, thecommunication manager may enable the encapsulated data to be routed to anetwork address of the destination VPC using the VPC identifier.

In accordance with embodiments of the present disclosure, the hostingsystem 802 further includes an adaptive DNS resolver 820 configured toprocess and handle DNS requests from computing devices of the VPCs 810(e.g., the servers 814) according to an identifier of the originatingVPC 810, as well as rules established by an administrator of the VPC810. Specifically, the adaptive DNS resolver 820 includes a rulesinterface 822 by which administrators of a VPC 810 may specify DNSresolution rules for devices of the VPC 810, a rules data store 824 inwhich the rules may be stored, and a resolver engine 826 configured toobtain DNS requests from devices of the VPC 810 and to process therequests according to the rules.

Illustratively, the rules interface 822 may provide user interfaces,such as command line interfaces (CLIs), application programminginterfaces (APIs), graphical users interfaces (GUIs), or the like,through which administrators of a VPC 810 may specify rules for handlingDNS requests from the devices of the VPC 810. In some instances, therules interface 822 may further handle authentication and verificationof submitted rules (e.g., by verifying that the request to add, modifyor remove a rule is accompanied by appropriate authenticationinformation, that the rule conforms to an expected format, etc.). Therules interface 822 may further handle addition of new rules to therules data store 824, or modification of the data included within therules data store 824. In this manner, the rules interface 822 mayprovide a “control plane” for controlling operation of the adaptive DNSresolver 820.

The various rules established by administrators of a VPC 810 can bestored in a rules data store 824, which can correspond to any persistentor substantially persistent data storage, such as a hard drive (HDD), asolid state drive (SDD), network attached storage (NAS), a tape drive,or any combination thereof. The rules data store 824 may be implementeddirectly by a physical storage device, or may be implemented by avirtualized storage device that is in turn implemented on an underlyingphysical storage device. While shown as a single data store, the rulesdata store 824 may in some instances be logically or physically divided.For example, a separate rules data store 824 may be provided for eachVPC 810.

The resolver engine 826 is illustratively configured to obtain DNSrequests from devices of a VPC 810, such as servers 814, and to processthe requests according to the rules within the rules data store 824.Illustratively, on receiving a request from a server 814, the resolverengine 826 may determine a VPC identifier associated with the server 814(e.g., as included in the request or metadata associated with therequest), and obtain one or more rules established by an administratorof the identified VPC 810. The resolver engine 826 may then use therules of the VPC 810 to determine what further processing, if any,should occur with to the DNS request. In one embodiment, a rule for aVPC 810 may include a domain name for which the rule applies, as well asan action to take with respect to a DNS request associated with thedomain name. For example, a first rule may indicate that any DNS requestfor the domain name “customer.tld” should be forwarded to a specific DNSserver, such as the customer DNS server 852 or a private DNS resolver812 of a given VPC 810. As a further example, a second rule may indicatethat DNS requests for “example.tld” should by handled via the public DNSsystem (e.g., by specifying that the request should be handled by aparticular public DNS server 860 or by specifying that the requestshould be handled according to the default operation of the hostingsystem 802, which may utilize a public DNS server 860). In someinstances, multiple rules may apply to a given domain name, and therules may be ordered such that a highest ranking rule is applied by theresolver engine 826 prior to or instead of a lower ranking rule.Furthermore, rules may in some instances specify a type of forwardingthat should occur with respect to a specific request. Illustratively,rules may specify whether a DNS request should be forwarded to aspecific DNS server as a “forwarding” request, “conditional forwarding”request, or “stub” request. These and other types of DNS request areknown in the art. In addition to forwarding, rules may in some instancesspecify that a DNS request should be handled directly by the adaptiveDNS resolver 820, such as by returning a specific network address orreturning no address at all (which may be utilized to “blackhole” therequest and prevent a requesting device from accessing resources at therequested domain). Thus, by use of the adaptive DNS resolver 820, DNSrequests from servers 810 or other devices of a VPC 810 may bedistributed between various public or private DNS servers, or otherwisehanded according to rules that can be specified by administrators ofVPCs 810.

FIG. 4 depicts one embodiment of an architecture of a server 900 thatmay implement the adaptive DNS resolver 820 of FIG. 3. The generalarchitecture of server 900 depicted in FIG. 4 includes an arrangement ofcomputer hardware and software components that may be used to implementaspects of the present disclosure. As illustrated, the server 900includes a processing unit 904, a network interface 906, a computerreadable medium drive 907, an input/output device interface 920, adisplay 922, and an input device 924, all of which may communicate withone another by way of a communication bus. The network interface 906 mayprovide connectivity to one or more networks or computing systems, suchas the internal network 830 of FIG. 3. The processing unit 904 may thusreceive information and instructions from other computing systems orservices via a network. The processing unit 904 may also communicate toand from memory 910 and further provide output information for anoptional display 909 via the input/output device interface 920. Theinput/output device interface 920 may also accept input from theoptional input device 924, such as a keyboard, mouse, digital pen, etc.In some embodiments, the server 900 may include more (or fewer)components than those shown in FIG. 4. For example, some embodiments ofthe server 900 may omit the display 902 and input device 924, whileproviding input/output capabilities through one or more alternativecommunication channel (e.g., via the network interface 906).

The memory 910 may include computer program instructions that theprocessing unit 904 executes in order to implement one or moreembodiments. The memory 910 generally includes RAM, ROM and/or otherpersistent or non-transitory memory. The memory 910 may store anoperating system 914 that provides computer program instructions for useby the processing unit 904 in the general administration and operationof the server 900. The memory 910 may further include computer programinstructions and other information for implementing aspects of thepresent disclosure. For example, in one embodiment, the memory 910includes user interface software 919 that implements the rules interface822, and which generates user interfaces (and/or instructions therefor)for display upon a computing device, e.g., via a navigation interfacesuch as a web browser installed on the computing device. In addition,memory 910 may include or communicate with one or more auxiliary datastores, such as data store 902, which may correspond to any persistentor substantially persistent data storage, such as a hard drive (HDD), asolid state drive (SDD), network attached storage (NAS), a tape drive,or any combination thereof, and which may implement the rules data store824. In addition, the memory 910 may include adaptive resolutionsoftware 916 that may be executed by the processing unit 904. In oneembodiment, the adaptive resolution software 916 implements theresolution engine 826 or other aspects of the present disclosure,including obtaining DNS resolution requests from devices of VPCs 810 andprocessing the requests according to a source VPC 810 of the request aswell as rules associated with that source VPC 810.

With reference to FIGS. 5A and 5B, a set of illustrative interactionsfor adaptive resolution of DNS requests from servers 814 of a VPC 810will be described. The interactions between at (1), where the adaptiveDNS resolver 820 obtains a set of resolution rules associated with a VPC810. Illustratively, the rules may be provided by an administrator ofthe VPC 810 via a web interface, API, CLI, or other user interfaceprovided by the rules interface 822. While not shown in 5A FIG. 5A,rules may be submitted to the rules interface 822 by an administratorcomputing device, which may include either or both devices within a VPC810 or outside a VPC 810 (e.g., outside of the host system 802). Oneexample set of rules in shown in TABLE 1, below.

TABLE 1 Rule ID Domain Action 1 *.example.tld default 2 *.Socialnet.tldblackhole 3 *.Payroll.customer.tld DNS SERVER 852 4*.Cloudapi.customer.tld DNS RESOLVER 812

As shown in TABLE 1, each rule may be associated with a rule identifier.In some instances, these rule identifiers may be unique among all VPCs810, such that rules may be shared among VPCs 810 by use of the ruleidentifiers. For example, an administrator of a first VPC 810 may applya rule originally created for a second VPC 810 by reference to the rulesidentifier. In other instances, the identifiers of each rule may belocalized to a specific VPC 810, and thus may overlap between VPCs 810.Each rule my further include a domain, as well as an action to take whena DNS request to resolve that domain is received. For example, Rule 1 ofTABLE 1 indicates that requests for the domain “example.tld” (where theasterisks represents any subdomain of that domain) should be handled viaa default DNS process of a host system, which may include passing therequest to a public DNS server. Rule 2 of TABLE 2 indicates thatrequests associated with the domain “socialnet.tld” (which may representa social networking site) should be “blackholed” or dropped, such thatno response is provided to the requesting device. Rule 3 of TABLE 1indicates that requests associated with the domain“payroll.customer.tld” should be forwarded to a specific DNS server,shown as DNS server 852, while rule 3 of TABLE 1 indicates that requestsassociated with the domain “cloudapi.customer.tld” should be forwardedto a different DNS server, shown as DNS resolver 812. In practice, theDNS servers may be identifier, for example, by a network address of theDNS server. While illustrative examples of rules are shown in TABLE 1,variations are possible and contemplated in the scope of thisdisclosure. For example, some embodiments may enable directspecification of a network address to which a domain should resolve(e.g., resolve requests to “example.tld” to IP address “1.2.3.4”). As afurther example, some embodiments may enable a rule to reference orcombine other rules (e.g., Rule 1 represents application of ruleidentifiers 7, 8, and 9, where those identifiers 7, 8, and 9 mayreference, for example, rules established with respect to another VPC810). As yet a further example, some embodiments may enable a rule toreference a collection of rules. Illustratively, an administrator of aVPC 810 may create a rule that references a collection of rulesestablished by a third party, which block access to malicious orobjectionable domain names. In the example of TABLE 1, a priority ofrules is established by their order within the table; however, otherembodiments may explicitly associate priorities or orderings withindividual rules or groups of rules. Further, in the example of TABLE 1,the depicted rules are assumed to apply to an individual VPC 810;however, other embodiments may explicitly indicate, within the rule, theVPCs 810 to which the rule applies, or identifiers of individual devices(e.g., within a VPC 810) to which the rule applies. In some instances,rules of different VPCs 810 may be maintained separately. In otherinstances, rules of different VPCs 810 may be stored collectively (e.g.,within a collective database).

Returning to the interactions of FIG. 5A, at (2), the rules interface822 stores the obtained rules associated with a VPC 810 into the rulesdata store 824. The rules may then be utilized to determine how tohandle DNS resolution requests received from devices, such as servers814, within the VPC 810 to which the rules apply. For example, in FIG.5A, a server 810 can transmit a DNS resolution request to the adaptiveDNS resolver 820 at (3). The request may, for example, request toresolve the domain “example.tld” into a corresponding network address.In some instances, the server 814 itself may be configured to transmitDNS resolution requests to the adaptive DNS resolver 820. In otherinstances, a substrate computing device hosting the server 814 may beconfigured to forward DNS resolution requests to the adaptive DNSresolver 820. The substrate computing device or another deviceassociated with the VPC 810 may further be configured to “tag” DNSresolution requests from servers 814 with an identifier of the VPC 810,such as by include the VPC identifier within the request itself, orencapsulating the request into data packets including the VPC identifier(e.g., a metadata). Thus, on receiving the resolution request, theadaptive DNS resolver 820 can identify the specific VPC 810 from whichthe request was received by detecting the VPC identifier included withinor associated with the request (which may include, for example,extracting the VPC identifier from data packets before decapsulating therequest from the data packets).

At (4), the adaptive DNS resolver 820 (e.g., via the resolver engine826) applies the rules of the VPC 810 to determine an action to takewith respect to the request. For example, if the request is to resolvethe domain “example.tld,” the adaptive DNS resolver 820 may consult therules shown in TABLE 1, and determine that rule ID “1” indicates thatthe request should be processed according to a default behavior withinthe host system 802, which may include processing the request accordingto standard DNS protocols (e.g., via a public DNS system). The adaptiveDNS resolver 820 may therefore determine a network address correspondingto the domain “example.tld” by requesting that address from a public DNSserver, such as public DNS server 860. In another example, if therequest was to resolve the domain “socialnet.tld,” the adaptive DNSresolver 820 may take no further action or may return an errornotification to the server 814, which may result in an error on therequesting server 814 that the domain could not be resolved. In yetanother example, if the request was to resolve the domain“payroll.customer.tld,” the adaptive DNS resolver 820 would then forwardthe request to a DNS server 852 within a data center 850, as specifiedby the rules. Thus, by application of rules set by an administrator ofthe VPC 810, the adaptive DNS resolver 820 may take any number ofactions with respect to DNS requests, including dividing DNS requestsbetween a number of potential public and private DNS servers.

One example of interactions between the adaptive DNS resolver 820 and adistinct DNS server is shown in FIG. 5B. Specifically, the interactionsof FIG. 5B are illustrative of those that may occur when the adaptiveDNS resolver 820 determines, based on rules for a given VPC 810, that aDNS resolution request should be forwarded to a customer DNS server 852of a data center 850. The numbering of interactions in FIG. 5B thuscontinues that shown in FIG. 5A. Specifically, at (5), the adaptive DNSresolver 820 transmits the resolution request, originally received fromthe server 814 of the VPC 810, to the customer DNS server 852 specifiedwithin the rules for the VPC 810. In some instances, the adaptive DNSresolver 820 may include additional information within the DNS requestthat would not otherwise typically be included within a standard DNSrequest. For example, the adaptive DNS resolver 820 may include anidentifier of the VPC 810 from which the request is received, anidentifier of the server 814 from which the request was received, orother information regarding a source of the request (e.g., a geographicregion associated with the VCP 810 or the server 814, etc.). In someinstances, the customer DNS server 852 may be configured to resolvedomain names differently based on the source of the request.

At (6), the customer DNS server 852 obtains the request to resolve thedomain name, and determines a network address into which the resolve thedomain name. In some instances, the customer DNS server 852 may havefirsthand knowledge of the network address into which the domain nameshould resolve, and may thus determine the network address frominformation local to the customer DNS server 852. In other instances,the customer DNS server 852 may interact with other DNS servers (notshown in FIG. 5B) to resolve the domain name into a network address.These other interactions are known within the art of DNS requestprocessing, and thus will not be described in detail.

At (7), the customer DNS server 852 returns a network addresscorresponding to the domain name of the original request to the adaptiveDNS resolver 820. The adaptive DNS resolver 820, in turn, returns thenetwork address to the server 814. Thus, the server 814 may successfullyresolve a domain name into a network address by use of a customer DNSserver 852, based on handling rules established by an administrator ofthe VPC 810. While FIG. 5B depicts a single query and response from theadaptive DNS resolver 820, in some instances the adaptive DNS resolver820 may make multiple queries in order to resolve a DNS request.Illustratively, a response obtained at the adaptive DNS resolver 820from the customer DNS server 852 may specify an additional DNS server(not shown in FIG. 5B) to which to transmit a request to resolve adomain name. The adaptive DNS resolver 820 may continue to process DNSresponses and query DNS servers until a network address responsive tothe query of the server 814 is obtained. While a network address is usedherein as an example of a type of response provided by a DNS system,other response contents are possible. For example, a DNS response mayinclude a TXT record (a text record), an SRV record, an MX record, orany other type of DNS resource record.

With reference to FIG. 6, one illustrative routine 1100 that may beimplemented to process DNS requests from devices within a VPC accordingto VPC-associated rules will be described. The routine 1100 may beimplemented, for example, by the adaptive DNS resolver 820 of FIG. 3.The routine 1100 begins at block 1102, where the adaptive DNS resolver820 obtains one or more resolution rules associated with a VPC. Suchrules may be submitted, for example, via a GUI (e.g., a web interface),CLI, or API, by an administrator of the VPC. Each rule may include adomain to which the rule applies and an action to undertake whenprocessing a request to resolve the domain. The actions may include, byway of non-limiting example, processing the request according to adefault behavior (e.g., public DNS resolution), forwarding the requestto a specific DNS server (either public or private), a type offorwarding to use when forwarding the request, resolving the requestinto a specified address, or halting further processing on the request.Each rule may further include additional information, such as specificdevices to which to the rule applies, such that the rule is onlyimplemented with respect to requests stemming from those device, or suchas a priority of the rule controlling the order in which the rule isapplied with respect to other rules.

At block 1104, the adaptive DNS resolver 820 obtains a DNS resolutionquery from a device within a VPC. Illustratively, the adaptive DNSresolver 820 may obtain a packet transmitted from the device, which maybe encapsulated with additional information by a host device. At block1106, the adaptive DNS resolver 820 determines a source VPC for therequest. Illustratively, the adaptive DNS resolver 820 may detect a VPCidentifier within the request (e.g., as a parameter of the DNS request,in accordance with the “EDNS,” or “extension mechanisms for DNS”specification) or as metadata associated with an encapsulation of therequest.

At block 1110, the adaptive DNS resolver 820 processes the requestaccording to the identified source VPC and the obtained rules todetermine an action specified by the rules. While a variety of actionsare possible under the embodiments disclosed herein, as described above,the routine 1100 is depicted as including three potential actions:conducting no resolution (e.g., “blackholing” the request); forwardingthe request to a private DNS server, which may be specified in acorresponding rule, or forwarding the request to a public DNS server.

As shown in FIG. 6, where the rules specify that no resolution for therequested domain should occur, the routine 1100 proceeds to block 1120and ends. While not shown in FIG. 6, in some instances, the adaptive DNSresolver 820 may additionally or alternatively return a response to therequesting device that no resolution is to occur, such as an errormessage or request denied message.

Where the rules specify that resolution is to occur via a specific DNSserver (which may be specified, for example, by network address or otheridentifier within the rules), the routine 1100 proceeds to block 1112,where the request is forwarded to the identified server. In someinstances, implementation of block 1112 may include supplementing therequest with additional information, such as an identifier of the VPC orthe device from which the request was obtained. Where the rules specifythat resolution is to occur via a public DNS server, the routine 1100proceeds to block 1114, where the request is forwarded to the public DNSserver. In some instances, the rules may specify a particular public DNSserver to use. In other instances, the rules may specify that a standardor default public DNS server (e.g., as would be otherwise used bycomponents of a host system) should be used. In either instance, theroutine 1100 then proceeds to block 1116, where a network address forthe domain name is obtained at the adaptive DNS resolver 820. Obtainingsuch a network address may include, for example, querying other DNSservers identified by the specific DNS server or public DNS serverqueried at block 1112 and 1114. At block 1118, the adaptive DNS resolver820 returns the network address to the requesting device. The routine1110 then ends at block 1120. Thus, by implementation of the routine1110, requests for DNS resolution obtained from devices within VPCs canbe distributed between various DNS resolution servers, or otherwiseprocessed, according to rules established by an administrator of a VPC.

One of skill in the art will appreciate that while the routine 1100 isdescribed as an ordered set of illustrative actions, the routine 1110may in some instances include additional or alternative interactions.For example, while the adaptive DNS resolver 820 is described asobtaining a network address from a DNS server, and transmitting thatnetwork address to a requesting device (and thus acting as a proxy orrelay for DNS resolution requests), the adaptive DNS resolver 820 may insome instances be configured to cause such network addresses to bereturned directly from a requesting device. For example, the adaptiveDNS resolver 820 (or other components of a host system) may transmit DNSresolution requests to a server, and modify the request such that aresponse is provided directly to the requesting device, rather than tothe adaptive DNS resolver 820. Such direct return of network addressesmay, for example, reduce the computing resources used by the adaptiveDNS resolver 820. Thus, the interactions of FIG. 6 should be viewed asillustrative.

All of the methods and processes described above may be embodied in, andfully automated via, software code modules executed by one or morecomputers or processors. The code modules may be stored in any type ofnon-transitory computer-readable medium or other computer storagedevice. Some or all of the methods may alternatively be embodied inspecialized computer hardware.

Conditional language such as, among others, “can,” “could,” “might” or“may,” unless specifically stated otherwise, are otherwise understoodwithin the context as used in general to present that certainembodiments include, while other embodiments do not include, certainfeatures, elements and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

Disjunctive language such as the phrase “at least one of X, Y or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y or Z, or any combination thereof (e.g., X, Y and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y or at least one of Z to each be present.

Unless otherwise explicitly stated, articles such as ‘a’ or ‘an’ shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

Any routine descriptions, elements or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or elements in the routine. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, orexecuted out of order from that shown or discussed, includingsubstantially synchronously or in reverse order, depending on thefunctionality involved as would be understood by those skilled in theart.

It should be emphasized that many variations and modifications may bemade to the above-described embodiments, the elements of which are to beunderstood as being among other acceptable examples. All suchmodifications and variations are intended to be included herein withinthe scope of this disclosure and protected by the following claims.

What is claimed is:
 1. A system for adaptive resolution of domain namesystem (DNS) requests obtained from devices of a virtual private cloudnetwork environment (VPC), wherein the VPC includes one or more virtualcomputing devices arranged within a virtualized local area network, thevirtualized local area network generated by a substrate network hostingthe VPC, the system comprising: a non-transitory data store includingdata identifying one or more rules designated by an administrator of theVPC for handling requests, the requests obtained from devices of theVPC, to resolve domain names into corresponding network addresses,wherein the one or more rules are separate from other rules associatedwith other VPCs; at least one computing device configured withcomputer-executable instructions that, when executed, cause the at leastone computing device to: obtain a request from a virtual computingdevice of the VPC to resolve a domain name into a corresponding networkaddress; determine, from a VPC identifier of the request, that therequest originates within the VPC; apply the one or more rules to therequest to determine a resolution server, designated within the one ormore rules, to which the request should be forwarded, wherein theresolution server designated within the one or more rules is a privateDNS server implemented within the VPC; forward the request to theresolution server designated within the one or more rules; obtain thecorresponding network address in response to the request; and return thecorresponding network address to the virtual computing device infulfillment of the request.
 2. The system of claim 1, wherein theprivate DNS server is identified within the one or more rules by atleast one of a network address or an identifier associated with the VPC.3. The system of claim 1, wherein the computer-executable instructionsfurther cause the at least one computing device to: obtain a secondrequest from the virtual computing device of the VPC to resolve a seconddomain name into a corresponding second network address; determine, froma VPC identifier of the second request, that the second requestoriginates within the VPC; determine, from the one or more rules, thatthe second request should not be further routed; and halt furtherrouting of the second request.
 4. A computer-implemented method foradaptive handling of domain names resolution requests obtained fromdevices of a virtual private cloud network environment (VPC), whereinthe VPC includes one or more computing devices arranged within avirtualized local area network, the virtualized local area networkgenerated by a substrate network hosting the VPC, thecomputer-implemented method comprising: obtaining, from an administratorof the VPC, one or more rules for handling requests to resolve domainnames into corresponding network addresses, wherein the one or morerules are separate from other rules associated with other VPCs, andwherein the requests are obtained from devices of the VPC; obtaining arequest from a computing device of the VPC to resolve a domain name intoa corresponding network address; determining, from a VPC identifier ofthe request, that the request originates within the VPC; applying theone or more rules to the request to determine a resolution server,designated within the one or more rules, to which the request should beforwarded, wherein the resolution server designated within the one ormore rules is a private DNS server implemented within the VPC;forwarding the request to the resolution server designated within theone or more rules; obtain the corresponding network address in responseto the request; and return the corresponding network address to thecomputing device in fulfillment of the request.
 5. Thecomputer-implemented method of claim 4 further comprising, prior toforwarding the request to the resolution server designated within theone or more rules, modifying the request to cause a response to therequest to be returned to the computing device.
 6. Thecomputer-implemented method of claim 4, wherein the request is formattedaccording to the domain name system (DNS) protocol.
 7. Thecomputer-implemented method of claim 4, wherein the resolution server isa default resolution server associated with the VPC, and wherein the oneor more rules designate the resolution server by reference to thedefault resolution server.
 8. The computer-implemented method of claim4, wherein obtaining the request from the computing device of the VPC toresolve the domain name into the corresponding network address comprisesobtaining the request in an encapsulated form, and decapsulating therequest.
 9. The computer-implemented method of claim 8 furthercomprising extracting the VPC identifier from metadata associated withthe encapsulated form.
 10. The computer-implemented method of claim 4further comprising: obtaining a second request from the computing deviceof the VPC to resolve a second domain name into a corresponding secondnetwork address; determining, from a VPC identifier of the secondrequest, that the second request originates within the VPC; determining,from the one or more rules, that the second request should not befurther routed; and halting further routing of the second request. 11.Non-transitory computer readable media including computer-executableinstructions for adaptive handling of domain names resolution requestsobtained from devices of a virtual private cloud network environment(VPC), wherein the VPC includes one or more computing devices arrangedwithin a virtualized local area network, the virtualized local areanetwork generated by a substrate network hosting the VPC, wherein thecomputer-executable instructions, when executed by a computing system,cause the computing system to: obtain one or more rules for handlingrequests to resolve domain names into corresponding network addresses,wherein the one or more rules are separate from other rules associatedwith other VPCs, and wherein the requests are obtained from devices ofthe VPC; obtain a request from a first computing device of the VPC toresolve a domain name into a corresponding network address; determine,from a VPC identifier of the request, that the request originates withinthe VPC; apply the one or more rules to the request to determine aresolution server, designated within the one or more rules, to which therequest should be forwarded, wherein the resolution server designatedwithin the one or more rules is a private DNS server implemented withinthe VPC; and route the request to the resolution server determined fromapplication of the one or more rules; obtain the corresponding networkaddress in response to the request; and return the corresponding networkaddress to the computing device in fulfillment of the request.
 12. Thenon-transitory computer readable media of claim 11, wherein thecomputer-executable instructions further cause the computing system todetermine the VPC identifier from a flag field of the request.
 13. Thenon-transitory computer readable media of claim 11, wherein thecomputer-executable instructions further cause the computing system to:obtain a modification to the one or more rules, the modificationprovided by the administrator of the VPC; and update the one or morerules according to the modification.
 14. The non-transitory computerreadable media of claim 11, wherein at least one rule of the one or morerules references another rules associated with another VPC.
 15. Thenon-transitory computer readable media of claim 11, wherein determiningthe resolution server, designated within the one or more rules, to whichthe request should be forwarded further includes determining a domainname system (DNS) forwarding type to utilize in further routing of therequest.
 16. The non-transitory computer readable media of claim 11, therequest is obtained in an encapsulated form, and wherein thecomputer-executable instructions further cause the computing system todecapsulate the request.